@lassoan @pieper What do you think ? Is it reasonable to integrate this before doing the release ?

@leochan2009 How critical is this patch ? Have you thoroughly tested ? Since we are releasing Slicer 4.8 tonight I am reluctant to integrate this now.

Hi Jean,

Thanks for the prompt reply.
It is not critical at all, i tested it on my mac only.
I think we could integrate this after the release.

Best,
Longquan

@leochan2009 this will work with default output settings/tools, but FiberBundleNode doesn't necessarily require tensors -- UKFTractography allows to disable tensor output. So just be aware that the heuristic will not be 100% accurate.

Also, if somebody sends a model node that contains tensor data (for example, stress tensor is computed as a result of finite-element analysis) this code would incorrectly create a fiber bundle node for it.

I would suggest to revert this commit and introduce a different device type for fiber bundle data. You can keep the vtkIGTLToMRMLPolyData class read/write these nodes and just use the device type to indicate that the data should be written to a fiber bundle node.

Hi Andras,
Great suggestion, currently the mrmlnode created is based on the content of the polydata,
Which is just a quick workaround for the problem of fiberbundle transmission.
I could add a class derived from the igtlPolyDataMessage with deviceType "FiberBundle" into the OpenIGTLink protocol. Also this method could probably solve another problem with color image. #54

We could also utilize metadata in OpenIGTLinkv3 - add a custom key/value pair to indicate that the polydata contains fiber bundle (e.g., SUBTYPE=FIBER_BUNDLE).

I agree with @lassoan. The OpenIGTLinkIF module should have a mechanism for an OpenIGTLink client (sender) to specify a target MRML type for data conversion in Slicer, because we've seen some use cases where OpenIGTLink messages have to be converted to non-standard types. I would name it MRML_TYPE rather than SUBTYPE.

Hi All,

I agree with Andras and Junichi to use the the metadata for creating mrmlNode.
This method will solve the mismatch issue between message type and Mrmlnode.
But this solution will create problems when two computer have different version of OpenIGTLink protocol. Set/Get Meta information is only available in recent OpenIGTLink library.
Probably i could add a checkbox in the IF module to send old OpenIGTLink message.

Best,
Longquan

Worst that can happen that the old OpenIGTLink client will not get the metadata. I think PLUS toolkit's PlusServer has already a mechanism to determine what version of OpenIGTLink the client can understand and send only compatible messages. This mechanism is implemented is or will be implemented in OpenIGTLinkIO, so when we'll port OpenIGTLinkIF to use OpenIGTLinkIO, it will automatically get this feature.

@adamrankin

Hi Andras,
I have another OpenIGTLinkIF module that depends on OpenIGTLinkIO library. Will check if the feature is inside.